Release 10.1A: OpenEdge Development:
Progress Dynamics Advanced Development

Joining customizations to the SmartObject table

The customizations by themselves do not affect the application. The key data relationship here is between the customization_result table and the SmartObject table. This is where the run time effects of the customizations are defined.

As we noted in the discussion on the SmartObject table, the unique key for that table (beyond its object ID) is not just the object_filename, but also the customization_result_obj field. For the standard object behavior, the customization_result_obj is 0. For customized behavior, it is joined to the customization_result table using this field. This means that there must be a distinct SmartObject record for each customization result code that applies to the object. If a viewer, for example, has been customized to have different behavior (such as different field positions or different fields enabled or displayed) for each of six different user categories and three different user interface types, such as GUI, CUI, and WBS, then there will be a total of ten ryc_smartobject records representing that one object: one for the default definition, six for the user categories, and three for the UI types.

Each of these ryc_smartobject records will have its own set of attribute_value records that define it. The SmartObject record with no customization_result_obj will define all the default attribute values. Each of the other SmartObject records will define only whatever specific attribute values have been modified for that customization. Thus, the SmartObject records with a customization_result_obj are incomplete and cannot be used by themselves to build the object at run time. Their values can only be applied to modify the base attributes defined by the default SmartObject record.

At run time, the Customization Manager determines the result codes that apply to the session for each customization type by running the functions defined in the customization_type API_reference_name field. This yields a delimited list that remains available for the remainder of the session. The Repository Manager then combines the various attributes joined to all of the applicable SmartObject records. It does this by using the result code list to identify which customization_result records to join to the SmartObject table to retrieve all the applicable attribute_values. If multiple customizations apply, a function called getSessionResultCodes in the Customization manager determines the priority of them. Those with the highest priority are applied last, so that they take precedence if there are conflicting values for other customization types.

For example, suppose that user George logs in to a Progress Dynamics session running on WebSpeed using the new browser-based Progress Dynamics UI. George is a data entry clerk. Three result codes apply to this session:

User: George
UserCategory: Clerk
UIType: WBS

Suppose that this list represents the priority order of the customization types. (Customization type priority can in fact be defined and modified by session type.) When George runs a dynamic Customer Maintenance window as part of the application, a viewer inside the window has been customized in the following several different ways:

George requested that the tab order of the fields be modified so that the data entry process for the Customer Comments field and the Contact field are more convenient for his data entry routine. He also requested that the Comments editor be made larger.
George’s group manager defined a customization to the same viewer to disable the Contact field for clerks.
The Web application customization chief determined that the Comments editor for the dynamic HTML interface should be made smaller to look better in that environment.

The result of all of this is that:

The Comments field tab order is set as George requested it.
The Contact field tab order is irrelevant because the field is disabled for George as a clerk.
The size of the Comments editor is determined by the WBS definition because that takes precedence over George’s personal request that is defined at the user level.

Customizations can be defined only for attributes of SmartObject records, not directly for individual instances. However, you can define customizations at the level of a container window, which can be a way of accomplishing the same thing. In other words, the customizations are always done starting at the level of a SmartObject record. If that SmartObject record represents a container window, then it points to not only its attribute_value records, but also to object_instance records and their links and page records. Customizations can be done to the container by adding objects to the container or by modifying the attributes of objects inside the window for that window customization.

Figure 8–18 shows some of the records involved in defining these relationships.

Figure 8–18: Customization example

Figure 8–18 illustrates the following customization:

George is a clerk, and customizations have been defined for the UserCategory Clerk, one of which is that the Customer viewer customerviewv has a height of 12 rather than its default height of 10.
When George logs in, the Customization Manager assembles a list of all the appropriate result codes for his session. One of those is for UserCategory. The customization table defines a customization_reference for George for the UserCategory customization_type that maps to the result code Clerk in the customization_result table. As a result, the Customization Manager stored Clerk as the session result code for the UserCategory type.
When the system goes to run a window using the customerviewv viewer, the Repository Manager must build a list of all the viewer’s attributes. To do this, it locates all the SmartObject records that apply for this session for the viewer. In this case, that means both the default SmartObject, with no customization_result code, and also the SmartObject with the customization_result code for Clerk. It applies all the standard attribute values for the default version of the SmartObject (including the MinHeight value of 10), and then applies the attribute values for the customization, one of which overrides the MinHeight and sets it to 12. These values are then sent to the Layout Manager to use to build the window.